查看原文
其他

百度在故障定位场景下的监控数据可视化探索

2018-03-07 运小炜 DBAplus社群


作者介绍

运小炜,百度高级研发工程师,负责百度智能监控平台的设计和研发工作,在系统监控、业务监控等方向有广泛的实践经验。


干货概览


百度拥有上百条产品线、数十万的服务,每个服务时时刻刻都在产生着海量的监控数据,形成的监控项规模总数已达数十亿。面对如此海量的数据,在日常运维(如故障诊断、成本分析、性能优化等场景)过程中,传统的统计图表难以有效直观地展示如此庞大的数据。


因此,优秀的监控数据可视化产品就呼之欲出,它既要数据准确、全面、时效性高,也需要提升用户的使用体验,使其能在茫茫数据中一眼就能发现想要观察的数据。


那怎么做才能适应用户需求、完成精准展示,同时又能挖掘数据价值呢?下面我们从故障诊断的场景出发,来看百度智能监控平台是如何充分利用数据可视化武器来解决实际业务问题的。



故障定位可视化思路


在标准的故障处理流程中,故障定位一般可分为两个阶段:


故障止损前:期望可以快速获得可用于止损决策的信息,做出相应的止损操作使得服务恢复。比如通过确定故障范围,调度流量绕过故障机房或摘除故障实例等。


故障止损后:仍需要进一步找到导致故障的深层次原因,确定故障根因,将线上环境恢复到正常状态。


基于上面的需求,可以总结为以下三个定位的层次,从整体到局部逐步缩小故障范围,找到故障根因:


全局问题定位:快速确认线上状态,缩小故障判定范围。为可能的止损操作提供判断依据。本文会介绍如何构建一个全景分析仪表盘。


细分维度定位:通过分析地域、机房、模块、接口、错误码等细分维度,进一步缩小问题范围,确定需要排障的目标模块、接口等。本文会介绍如何基于多维度数据可视化解决维度数量暴增带来的定位难题。


故障根因确认:一些情况下,问题的根因需要借助除监控指标之外的数据进行分析。例如上线变更、运营活动导致的故障。本文针对导致故障占比最高的变更上线类故障进行分析,看如何快速找到可能导致故障的变更事件。



    全景掌控缩小范围


    对于一个服务乃至一条产品线而言,拥有一个布局合理、信息丰富的全景监控仪表盘(Dashboard)对于服务状态全景掌控至关重要,因此在百度智能监控平台中,我们提供了一款可定制化的、组件丰富的仪表盘服务。


    用户可以根据服务的特征,自由灵活的组织仪表盘布局,配置所需要展示的数据信息。



    如上图所示,我们可以按照问题定位的思路,将服务整体的服务可用性情况、分功能可用性情况、分模块的核心指标、流量的同环比对比、分IDC的流量对比等,依次通过丰富的可视化组件进行呈现。使得在收到报警时,可以快速将故障缩小到具体功能、模块、接入流量、机房级别。



    深入数据确定根因


    在故障处理过程中,全景数据仪表盘为我们缩小了故障定位的范围,但大多数的根因仍然隐藏在数据的细分维度中。由此多维度分析的重要性就体现出来了。常见的多维度分析包括如下几种场景:


    单维度取值对比分析:针对同一个维度的不同取值进行对比分析,例如确定流量下跌出现在哪个省份。


    多维度关联分析:分析两个甚至更多维度互相作用后数据的分析,例如如何确定一个下跌是机房级别还是模块级别。


    维度下钻分析:一些维度包含多个层级,例如省份、城市等相关联维度的逐层下钻定位。


    我们针对这些场景,设计了相应的解决方案。


    单纬度取值对比分析


    维度取值对比分析是一种最常见的细分维度定位方式。对于同一个维度下取值数量较少的情况,可以通过多维度趋势图和饼图等可视化方式进行快速的分析,查看不同维度取值的取值状态,以及占整体比例情况。


    而对于维度取值数量多,且不同取值数量级差距较大情况(例如分省份的流量下跌判定),使用饼图或趋势图很容易把流量较小省份的信息隐藏掉。这种场景下,我们可以通过维度取值自动展开功能,分别查看每个省份的状态。



    多个纬度关联分析


    细分维度的故障所带来的表象可能会在多个维度均有表现,比如服务整体的访问拒绝上升,我们会发现分机房的拒绝量上升,也看到分模块的拒绝上升。


    那么我们如何确认故障的根因是来源于某个机房还是某个模块,还是这两者的交叉维度,即某个机房的某个模块导致的问题。


    矩阵热力图可以解决这一问题。将需要做分析的两个维度分别作为横纵坐标,通过阶梯的阈值颜色将对应交叉维度的取值展现再坐标上。我们便可非常直观的看到这这两个维度对于整个业务的影响情况,如下图所示:



    我们可以看到,从纵向的分模块维度,可以看到Module 4在多个机房都有明显的访问拒绝情况,而在横向分机房维度,则没有明显的特征。则说明是Module 4模块导致的问题。


    嵌套纬度下钻分析


    类似于国家-省份-城市的行政区域划分,区域-机房-机器的服务部署划分,我们可以看到很多维度之间存在着层次嵌套的关系。我们故障定位的思路也是如此,从整体到局部逐步分层下钻定位。


    我们提供了多维度展开报表功能支持这种下钻分析。



    例如我们怀疑是某几台服务器导致的拒绝量上升,我们可以基于多维度统计报表,点击排序找到拒绝最大的区域,然后依次展开找到拒绝最大的机房和机器。


    点击详情后,我们就可以跳转到机器对应的页面,查看对应机器的详细数据来进行定位。




    找寻关联事件定位


    根据历史经验,大多数的线上故障都是由于变更操作所引起的,包括程序、数据、配置等变更事件,增删机器实例、执行预案等运维事件,甚至包括可能引发流量突增的活动运营事件。对于某些体积庞大的产品线,开发和维护人员众多,以上事件的发生更是千丝万缕、错综复杂。


    面对这个问题,我们设计并推出了一种可以解决这种问题的通用性组件——事件流图



    通过事件流图,可以快速筛选出故障的前后时间,发生或发生中的事件,每个事件通过色块的长短位置,展示了开始结束时间以及持续时长。我们可以快速的分析出对应时间的故障可能是由于某些操作开始或操作完成引发的。


    对于部分业务线,同一时间段发生的事件可能有上百甚至上千条,我们提供便捷的筛选功能来解决这一问题。通过事件类型标签,打开或关闭某一类事件的展示,优先排查最有可能的根因。同时对于每一类事件的支持细分筛选,用户可以自定义事件筛选的条件,支持多项选择、文本模糊匹配等多种方式,使得定位范围一层层缩小,最终找到问题根因。



    总结


    以上我们介绍了百度智能监控平台在全局故障分析、细分维度定位、事件关联定位三个故障定位阶段中进行的数据可视化探索。


    数据可视化能力的优势不仅仅在故障定位场景中有突出体现,还能应用在更多的数据分析领域。我们未来会进一步介绍平台在应用性能分析、商业数据分析等领域的实践成果,欢迎各位继续关注。


    文章转自AIOps智能运维(AI_Ops)订阅号,经平台同意授权转载



    近期热文

    详解主流Java应用服务器的工作原理及组件设计

    提前排雷!分布式缓存的25个优秀实践与线上案例

    借鉴Codis实现的两种不停机分库分表迁移方案

    从Elasticsearch集群及数据层架构,看分布式系统设计

    DBA+工具:SQL自审自上线,摆脱人肉审核就在当下 


    最新活动

    大数据与机器学习技术沙龙(上海站)

    (点此链接或图片了解更多详情)


    2018 Gdevops全球敏捷运维峰会(成都站)

    (点此链接或图片了解更多详情)

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存